Interactive web applications often require the use of electronic forms. There are multiple specifications for forms-based applications which describe the user interface, data model definition and associated processing model for forms-based applications. The following aspects of a forms-based application can be defined:
The data model for a form, which defines the data to be manipulated, the associated data types and any constraints that must be applied to the data;
The user interface (UI) for a form, which allows for user interaction with the data; and
The processing model for a form, which defines actions to be performed based on events which occur during the form lifecycle and events raised.
Typically, the UI represents everything the user sees and the events they trigger on those controls. The form processor specifies, amongst other things, event processing, data binding and validation and support for submitting the completed form to a database.
The data model and user interface elements of the form can be provided in a markup language such as XML (extensible Markup Language) in the form of a template. The user interface of the template can be rendered for display of the form to a user. A form processor (often also called a form processing engine) uses the processing model prescribed by the specification to read and process user inputs to the form.
A form designer can create a user interface with controls that drive the associated form processing model, by linking a form action with a control event, for example by associating a ‘form submit’ action with a ‘button clicked’ event. The form designer can also associate actions with form lifecycle events, for example associate a ‘set value’ action with a ‘form loaded’ event. This association process is sometimes called binding.
Efforts are being made to standardize web forms such that a standard form processor can be used to process forms. One such standard is the XForms 1.0 specification, which is recommended by the World Wide Web Consortium (W3C), and which can be found at http://www.w3.org/TR/xforms/.
One problem that can arise is if the forms-based application wants to drive form processing using controls which are external to the form template, for example to provide a button in a toolbar which will trigger the submit action.
One known way to do this is to include a button form control in the form template and associate it with the form submit action. This would mean that for an application consisting of a large number of form templates each one would need to contain the same construct in a uniform manner to provide a consistent user experience. For example to provide a toolbar in the application every form template would have to include content representing the toolbar. Therefore to change the toolbar every single form template would have to be changed.
Consider the following example where the goal is to design a form 100, such as that shown in FIG. 2, with the following functionality:
1) A user can enter in address information for a set of customers; in this example by including text boxes for customer name 102, three address lines 104, 106, 108, city 110, state 112 and postal code 114;
2) Navigation is provided to view the previous and next address, in this example by forward and back buttons 1 and 2;
3) Options are provided to:                create a new address record (button 3);        save the current changes (button 4);        delete an address record (button 5);        duplicate an address record (button 6); and        refresh the display with the last saved address records (button 7).        
Here are some extracts which illustrate how this would be represented using a typical form definition language, such as XForms, for which this problem occurs.
The first section, shown below in Listing 1, represents the buttons which run along the top of the form.
Listing 1:<xforms:trigger id=“button1” style=“image:url(previous.gif)”>   <xforms:action ev:event=“DOMActivate”>   <xforms:setindex index=“index(repeat_id ‘’) −   1”repeat=“repeat_id”/>   </xforms:action>  </xforms:trigger>  <xforms:trigger id=“button2” image:url(next.gif)”>   <xforms:action ev:event=“DOMActivate”>   <xforms:setindex index=“ index(repeat_id ‘’) +   1”repeat=“repeat_id”/>  </xforms:action> </xforms:trigger> <xforms:trigger id=“button3”>  <xforms:label >New</xforms:label>  <xforms:action ev:event=“DOMActivate”>  <ibmforms:insert/>  </xforms:action>  </xforms:trigger>  <xforms:trigger id=“button4”>  <xforms:label>Save</xforms:label>  <xforms:action ev:event=“DOMActivate”>   <xforms:send submission=“defaultSubmit”/>  </xforms:action>  </xforms:trigger>   <xforms:trigger id=“button5”>   <xforms:label>Delete</xforms:label>   <xforms:action ev:event=“DOMActivate”>    <xforms:delete repeat=“repeat_id”/>   </xforms:action>  </xforms:trigger>  <xforms:trigger id=“button6”>   <xforms:label>Duplicate</xforms:label>   <xforms:action ev:event=“DOMActivate”>    <ibmforms:duplicate/>   </xforms:action>  </xforms:trigger>  <xforms:trigger id=“button7”>   <xforms:label>Refresh</xforms:label>   <xforms:action ev:event=“DOMActivate”>    <xforms:refresh/>   </xforms:action>  </xforms:trigger>
The second section, shown below in Listing 2, represents the controls for entering the address information.
Listing 2: <xforms:input id=“edit1” ref=“@NAME”> <xforms:label>Name:</xforms:label></xforms:input><xforms:input id=“edit3” ref=“@ADDRESS1”> <xforms:label>Address 1:</xforms:label></xforms:input><xforms:input id=“edit4” ref=“@ADDRESS2”> <xforms:label>Address 2:</xforms:label> </xforms:input> <xforms:input id=“edit5” ref=“@ADDRESS3”>  <xforms:label>Address 3:</xforms:label> </xforms:input> <xforms:input id=“edit6” ref=“@CITY”>  <xforms:label>City:</xforms:label> </xforms:input> <xforms:input id=“edit7” ref=“@STATE”>  <xforms:label>State:</xforms:label> </xforms:input> <xforms:input id=“edit8” ref=“@POSTAL”>  <xforms:label>Postal:</xforms:label> </xforms:input>
If the form designer wants every form to have the same list of options i.e. previous record, next record, save, delete, etc. then every form template needs to contain the first section. Therefore, to change the options every single form template would have to be changed.
For example the addition of a reset button, would require the addition of an XForms trigger form control and an associated XForms reset action in every template. For an application consisting of a large number of form templates this would be a time consuming process.
An alternative solution would be to adapt the form processor to provide means for external user interface components to drive the form processing model. However, this would move away from the standard form processors, for example this would make an XForms Processor non-conformant with the XForms specification.
The present invention aims to address these problems.